home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
internet-drafts
/
draft-ietf-frnetmib-virtual-sma-00.txt
< prev
next >
Wrap
Text File
|
1993-06-16
|
40KB
|
1,065 lines
Draft Service Management Architecture June 1993
Service Management Architecture
for Virtual Connection Services
June 14, 1993
Frame Relay Service MIB (frnetmib) Working Group
Kenneth R. Rodemann
AT&T Bell Laboratories
krr@qsun.att.com
1. Status of this Memo
This document is an Internet Draft. Internet Drafts are
working documents of the Internet Engineering Task Force
(IETF), its Areas, and its Working Groups. Note that other
groups may also distribute working documents as Internet
Drafts.
Internet Drafts are draft documents valid for a maximum of
six months. Internet Drafts may be updated, replaced, or
obsoleted by other documents at any time. It is not
appropriate to use Internet Drafts as reference material or
to cite them other than as a "working draft" or "work in
progress."
Please check the I-D abstract listing contained in each
Internet Draft directory to learn the current status of this
or any other Internet Draft.
Rodemann Expires Dec 19, 1993 [Page 1]
Draft Service Management Architecture June 1993
2. Abstract
This document presents the Service Management Architecture,
an architectural framework for defining SNMP MIB modules for
Customer Network Management (CNM) of network services over
connection-oriented networks. The work is motivated by the
fundamental differences in management views and
functionality between a service provider and a service
customer. Differences between service provider and service
customer include whole-network vs. network-portion view,
direct vs. indirect management, and physical vs. logical
view. These fundamental differences suggest a difference in
philosophy between Service Management and Device Management.
Much work has been done and experience gained in writing
Device MIB modules for hands-on management of physical
devices, but defining Service MIB modules is a relatively
new area and requires the development of a new architectural
framework.
Rodemann Expires Dec 19, 1993 [Page 2]
Draft Service Management Architecture June 1993
3. Introduction
This document presents the Service Management Architecture,
an architectural framework for defining SNMP MIB modules for
Customer Network Management (CNM) of network services over
shared networks. Network providers offer a myriad of
network services, such as X.25, SMDS, Frame Relay, and ATM.
Some of these provide connection-oriented service, while
others provide connectionless service. CNM services are
becoming an important extension of these transport services
to provide customers with a management window into their
portion of the shared service. This document focuses on an
SNMP-based architectural framework for CNM of
connection-oriented network services.
The purpose of this work is to identify the notion of a
Service MIB module, and to define an architectural framework
for its definition that will permit easy extensibility and
interoperability across various network services. In order
to explore and understand how Service and Device management
differ, consider the following fundamental differences in
network management functionality between a network service
provider and a service customer.
First, service providers are responsible for managing the
entire shared network as a whole, while service customers
only view and manage their individual portions of the shared
service. Because they have a restricted view of the
network, customers are unable to perform certain network
management functions in the shared environment. For
example, a customer which sets routes for optimized
throughput of their own traffic may disrupt another
customer's traffic. Only the service provider, with a
complete view of the entire network, is in a position to
determine routes that allow provisioned access to network
resources for all customers.
A second fundamental difference in management functionality
is that service providers manage the network internals
directly, while customers manage their portion of the shared
network indirectly. The service provider is responsible for
the overall operation of the shared network, so any
management control offered to customers must first be
approved (perhaps manually) by the service provider before
the control request takes effect in the network.
Rodemann Expires Dec 19, 1993 [Page 3]
Draft Service Management Architecture June 1993
Finally, while service providers see a physical view of the
network, customers see a logical view. This logical view
includes the customer's configuration of service access
points (ports) and the virtual connections that run between
these ports. The customer does not see the individual
network switches along the paths of its virtual
connections---setting up physical routes is a responsibility
of the service provider.
These fundamental differences in network management
functionality suggest that there is a wholly different
philosophy between Service Management and Device Management.
A Device MIB module allows for hands-on management of a
physical entity. A Service MIB module provides to customers
a logical view of the customer's portion of a shared network
service by modeling the service, not the underlying
implementation or devices. Much work has been done and
experience gained in writing Device MIB modules for hands-on
management of physical devices, but defining Service MIB
modules is a relatively new area and requires the
development of a new architectural framework.
Rodemann Expires Dec 19, 1993 [Page 4]
Draft Service Management Architecture June 1993
4. Service Architecture
A connection-oriented network service offered by a service
provider can be viewed as a logical configuration of service
access points (ports), access channels, and virtual
connections (see Figure 1). Note that the term 'port' is
used instead of 'interface' to distinguish between a service
access point and a physical device access point.
+---------------------+
| |
###@=====================@###
|\ |
| =================== |
| \|
| @###
| /|
| =================== |
|/ |
###@=====================@###
| |
+---------------------+
Where @ is a service access point (port)
### is an access channel
=== is a virtual connection through
the service provider's network
Figure 1:
Logical view of a connection-oriented network
service, including service access points (ports),
access channels, and virtual connections.
The service provider manages the internals of the network
(switch and trunk acquisition/placement, virtual connection
provisioning/routing, internal fault detection/correction,
etc.), so the service customer need not be concerned with
such aspects. Instead, the service customer views and
indirectly manages the components in its logical view of the
service offering.
Rodemann Expires Dec 19, 1993 [Page 5]
Draft Service Management Architecture June 1993
A customer may subscribe to the services of more than one
service provider, with end-to-end virtual connections that
span multiple service providers' networks. These
multi-segment virtual connections can be viewed as a
concatenation of individual service-provider views (see
Figure 2).
+---------+ +---------+ +---------+
| Service | | Service | | Service |
| Provider| | Provider| | Provider|
------+ | A | | B | | C | +------
| | | | | | | |
Cust |###@=========@###@=========@###@=========@###| Cust
| | | | | | | |
------+ | | | | | | +------
+---------+ +---------+ +---------+
Figure 2:
Logical view of a customer's end-to-end
virtual connection that spans across
multiple service providers' networks.
The end-to-end view is a concatenation
of individual service-provider views.
The next section discusses the Service Management
Architecture, modeled upon the service architecture just
presented.
Rodemann Expires Dec 19, 1993 [Page 6]
Draft Service Management Architecture June 1993
5. Service Management Architecture
We previously discussed fundamental differences in network
management functionality between a service provider and a
service customer. These fundamental differences led to a
distinction between a Device MIB module and a Service MIB
module. A Service MIB module models the offered service, so
we now apply the preceding Service Architecture to derive a
generic Service MIB Module Architecture.
There exist two views of virtual connections within the
Service Architecture: service-provider views and customer
end-to-end views. Service-provider views consist of
single-segment virtual connections established through a
single service provider's network. Customer end-to-end
views consist of multi-segment end-to-end virtual
connections that span across multiple service providers'
networks. This end-to-end view represents a multi-segment
virtual connection as a concatenation of individual
service-provider segments. We first consider the
service-provider view, then briefly outline the customer
end-to-end view.
5.1 Service-Provider View
The Service Architecture identifies three types of service
objects within the service-provider view: service access
points (ports), access channels, and virtual connections. A
customer's logical configuration of service objects can be
defined in generic terms, without knowledge of the
underlying datalink protocol (X.25, Frame Relay, ATM, etc.)
of the service offering. Defining the configuration in such
a protocol-generic fashion will give to customers a
consistent end-to-end view of interworking services.
The first issue is how to identify a customer's service
objects. For protocol-generic identification, the Service
Management Architecture uses logical identifiers as follows:
Ports - Since customers view a provider's service as a
single entity, port id is a logical identifier
unique within the service provider's offering.
The service provider is free to choose port
identifiers as it sees fit.
Rodemann Expires Dec 19, 1993 [Page 7]
Draft Service Management Architecture June 1993
Access Channels - The Service Management Architecture
does not specify an identification scheme for
access channels. Because of the one-to-one
association of access channels to ports, the
Service Management Architecture places access
channel reference information with the
associated port.
Virtual Connections - Virtual connections are logical
data transport connections between a pair of
ports. Each end of a virtual connection is
separately identified by a tuple
(port id, VC id). The VC id is a logical
identifier unique to the associated port, and
is assigned by the service provider as it sees
fit. The service provider *may* map the VC id
directly to the addressing scheme used in the
underlying protocol (e.g., DLCI for Frame
Relay), but this is not necessary.
The next issue is how to structure the MIB information
within the Service Management Architecture. Service objects
have certain attributes that are protocol-generic, and other
attributes that are protocol-specific. For example,
protocol-generic attributes for virtual connections include
connection status and the identification of the remote end
of the connection. Protocol-specific attributes for virtual
connections include the underlying protocol's address of the
connection (DLCI for Frame Relay, VPI/VCI for ATM) and
protocol-specific service attributes (CIR for Frame Relay,
traffic class for ATM).
To provide consistent views across interworking of services,
the top level of the Service Management Architecture
consists of protocol-generic MIB modules that contain
generic object information and references to
protocol-specific MIB modules. The Management Architecture
includes a protocol-generic MIB module for ports and a
protocol-generic MIB module for virtual connections.
Rodemann Expires Dec 19, 1993 [Page 8]
Draft Service Management Architecture June 1993
First, consider a protocol-generic MIB module for ports.
A port has a logical identifier.
A port may have a global address.
A port has a current state.
A port interface is either User-Network (UNI) or
Network-Network (NNI).
A port may have associated location information and
contact information.
A port has protocol-specific port information.
A port has an associated physical access channel.
A port runs a specific link management protocol over
the access channel.
So, here is a first pass for a protocol-generic port MIB
module:
+ port id
+ global addressing info
+ port status info
+ UNI/NNI indicator
+ contact/location info
+ reference to (OID of) protocol-specific port MIB
entry (Frame Relay, ATM, X.25, etc.)
+ reference to (OID of) specific physical layer
MIB entry (DS1/E1, DS3, etc.)
+ reference to (OID of) specific link management
MIB entry (LMI, ILMI, Annex A, Annex B, etc.)
Just a footnote on the difference between port id and global
address: Port id is a logical identifier unique only within
a given service-provider's network (i.e., has local
significance), while a global address is a port identifier
unique across all service providers' networks (i.e., has
global significance).
The protocol-generic port MIB module ties in with the
Interfaces Group as follows. A port is viewed as an
interface to the service-provider's network, so
ifIndex = port id. The value of ifType is the assigned
value for the type of port, e.g., Frame Relay, ATM, X.25,
etc. And ifSpecific is an OID that points to the entry in
the protocol-generic port MIB module.
Rodemann Expires Dec 19, 1993 [Page 9]
Draft Service Management Architecture June 1993
Next, consider a protocol-generic MIB module for virtual
connections.
A virtual connection has a local port id and VC id.
A virtual connection has a remote port id and VC id.
A virtual connection has a current state.
A virtual connection may be either Permanent or
Switched.
A virtual connection has protocol-specific virtual
connection information.
So, here is a first pass for a protocol-generic virtual
connection MIB module:
+ local port id
+ local VC id
+ remote port id
+ remote VC id
+ VC status info
+ Permanent/Switched VC indicator
+ reference to (OID of) protocol-specific virtual
connection MIB entry (Frame Relay, ATM, etc.)
Figure 3 shows the Service Management Architecture MIB
module structure, including the relationships between the
Interfaces Group module, protocol-generic MIB modules,
protocol-specific MIB modules, and access channel MIB
modules.
5.2 Protocol-Generic/Protocol-Specific Relationship
This section further explores the relationship between the
protocol-generic tables and the protocol-specific tables.
To set the stage, first consider differences in
functionality between the two sets of tables. The
protocol-generic tables serve two functions:
(1) to provide a consistent structure for defining
protocol-specific MIB module suites (i.e., separating
into distinct MIB tables the management information for
ports, virtual connections, access channels, and link
management protocols), and
(2) to provide the topological glue for defining
protocol-generic virtual connection configuration.
The function of the protocol-specific tables is to provide
the specific details of the particular protocol service.
Rodemann Expires Dec 19, 1993 [Page 10]
Draft Service Management Architecture June 1993
protocol-generic proto-specific
Interfaces port module port module
------------------- ------------------- --------------
| ifIndex=port id | -->| port id | -->| e.g. |
|-----------------| | |-----------------| | | FR |
| . | | | . | | | ATM |
| : | | | : | | | X.25 |
|-----------------| | |-----------------| | --------------
| ifType | | | proto-specific | |
| (e.g., FR, ATM) | | | port entry OID -+-- physical layer
|-----------------| | |-----------------| --------------
| . | | | physical layer | |->| e.g. |
| : | | | entry OID -----+-- | DS1/E1 |
|-----------------| | |-----------------| | DS3 |
| ifSpecific OID -+-- | link management | --------------
------------------- | entry OID -----+--
------------------- | link management
| --------------
-->| e.g. |
| LMI |
| ILMI |
| Annex A |
--------------
protocol-generic proto-specific
VC module VC module
------------------- --------------
| local port id | -->| |
|-----------------| | | e.g. |
| local VC id | | | FR |
|-----------------| | | ATM |
| . | | | X.25 |
| : | | | |
|-----------------| | --------------
| proto-specific | |
| VC entry OID -+--
-------------------
Figure 3:
Service Management Architecture MIB module structure
showing relationships between the Interfaces Group module,
protocol-generic MIB modules, protocol-specific MIB
modules, and access channel MIB modules.
Rodemann Expires Dec 19, 1993 [Page 11]
Draft Service Management Architecture June 1993
The protocol-generic tables and the protocol-specific tables
have a hierarchical relationship, with the protocol-generic
tables being at a "higher" level than the protocol-specific
tables. However, this does not imply that the
protocol-specific tables are fully reliant on the
protocol-generic tables. The Management Architecture
permits protocol-specific MIB module suites to be
self-contained, i.e., a protocol-specific suite may contain
its own configuration information for correlation of service
objects without the need for indirection through the
protocol-generic tables. Of course, correlation of
interworking service objects (for example, the remote end of
an interworking virtual connection) would require a
reference through the protocol-generic VC table.
Recall that the protocol-generic tables contain downward
references (OIDs) to entries in protocol-specific tables.
To allow for management of interworking service objects, the
reverse references must also be in place, i.e., upward
references from the protocol-specific tables to entries in
the protocol-generic tables. These upward references may be
either OIDs or indexes into the protocol-generic tables.
For protocol-specific VC tables, it is recommended that an
interworking flag or some other indication be used to tell
whether a virtual connection is an interworking connection
or not. If the connection is a non-interworking connection,
then the remote end can be referenced within the given
protocol-specific suite; else, the remote end must be
referenced through the protocol-generic tables.
The Service Management Architecture permits
protocol-specific suites to define their own table indexing,
independent of the protocol-generic indexing. For example,
a Frame Relay suite may index a PVC table on port/DLCI,
while an ATM suite may index a VPI connection table on
port/VPI and a VPI/VCI connection table on port/VPI/VCI.
The following shows an example scenario of the relationship
between protocol-generic tables and protocol-specific
tables. The example also demonstrates how the Service
Management Architecture provides a consistent management
view of a service provider's interworking service.
Figure 4 gives the configuration of a customer with 5 ports,
3 of which are Frame Relay ports (P1, P2, P3) and 2 are ATM
Rodemann Expires Dec 19, 1993 [Page 12]
Draft Service Management Architecture June 1993
ports (P4, P5). Of the customer's 4 virtual connections, 2
are pure Frame Relay connections, 1 is a pure ATM
connection, and 1 is an interworking connection between
Frame Relay and ATM. The customer accesses the service via
2 different types of access channels running various link
management protocols.
+---------------------+
FR P1| VC1 VC1 |P2 FR
DS1 ###@=====================@### DS1
LMI |\ | Annex A
| =================== |
| VC2 VC1\|P3 FR
| @### DS3
| VC1 VC2/| Annex B
| =================== |
ATM P4|/ |P5 ATM
DS3 ###@=====================@### DS3
ILMI | VC2 VC1 | ILMI
+---------------------+
Figure 4:
Example customer configuration of an interworking
service offered by a service provider. P<n> is
the logical port id and VC<n> is the logical
port-specific VC id. FR/ATM are the port-specific
datalink protocols, DS1/DS3 are the specific
physical layers, and LMI/Annex A/ Annex B/ILMI are
the specific link management protocols.
The protocol-generic port MIB module has 5 entries, and the
protocol-generic virtual connection MIB module has 8 entries
(one entry for each end of the 4 virtual circuits), as shown
in Figure 5. To complete the example, the Frame
Relay-specific and ATM-specific virtual connection MIB
modules are shown in Figure 6.
The example shows the downward and upward references between
the protocol-generic and protocol-specific tables (via an
index for the Frame Relay suite and an OID for the ATM
suite). Both protocol-specific VC MIB modules also indicate
if a virtual connection is an interworking connection---with
a DLCI value of -1 for the Frame Relay suite, and an
interworking flag value of 0 for the ATM suite.
Rodemann Expires Dec 19, 1993 [Page 13]
Draft Service Management Architecture June 1993
PROTOCOL-GENERIC PORT MODULE
(indexed on port-id)
============================
OID of OID of OID of
port proto-specific phys layer link mgmt
id port entry entry entry
---------------------------------------------------------
| 1 |...| *FR port entry #1 | *DS1/E1 #1 | *LMI #1 |
| 2 |...| *FR port entry #2 | *DS1/E1 #2 | *Annex A #1 |
| 3 |...| *FR port entry #3 | *DS3 #1 | *Annex B #1 |
| 4 |...| *ATM port entry #1 | *DS3 #2 | *ILMI #1 |
| 5 |...| *ATM port entry #2 | *DS3 #3 | *ILMI #2 |
---------------------------------------------------------
PROTOCOL-GENERIC VIRTUAL CONNECTION MODULE
(indexed on local-port-id/local-VC-id)
==========================================
OID of
table local local remote remote proto-specific
entry port id VC id port id VC id VC entry
-------------------------------------------------------
1 | 1 | 1 | 2 | 1 |...| *FR VC entry 1 |
2 | 1 | 2 | 3 | 1 |...| *FR VC entry 2 |
3 | 2 | 1 | 1 | 1 |...| *FR VC entry 3 |
4 | 3 | 1 | 1 | 2 |...| *FR VC entry 4 |
5 | 3 | 2 | 4 | 1 |...| *FR VC entry 5 |
6 | 4 | 1 | 3 | 2 |...| *ATM VC entry 1 |
7 | 4 | 2 | 5 | 1 |...| *ATM VC entry 2 |
8 | 5 | 1 | 4 | 2 |...| *ATM VC entry 3 |
-------------------------------------------------------
Figure 5:
Protocol-generic MIB modules showing table
indexing and the downward references within
the Service Management Architecture.
This example demonstrates how the Service Management
Architecture provides a consistent management view of:
+ interworking datalink protocol connections
+ various type of physical access channels
+ various link management protocols
Note also how easy it is to integrate new datalink protocol
Rodemann Expires Dec 19, 1993 [Page 14]
Draft Service Management Architecture June 1993
FR-SPECIFIC VC MODULE
(indexed on local-port/local-DLCI)
==================================
generic generic
table local local remote remote local remote
entry port DLCI port DLCI VC id VC id
---------------------------------------------------
1 | 1 | 100 | 2 | 200 | 1 | 1 | ... |
2 | 1 | 110 | 3 | 110 | 2 | 1 | ... |
3 | 2 | 200 | 1 | 100 | 1 | 1 | ... |
4 | 3 | 110 | 1 | 110 | 1 | 2 | ... |
5 | 3 | 200 | 4 | -1 | 2 | 1 | ... |
---------------------------------------------------
ATM-SPECIFIC VC MODULE
(indexed on local-port/local-VPI/local-VCI)
===========================================
OID of
table local local local generic I/W remote remote remote
entry port VPI VCI VC entry flag port VPI VCI
-------------------------------------------------------
1 | 4 | 100 | 10 | *entry 6 | 0 | 3 | 0 | 0 |...|
2 | 4 | 110 | 10 | *entry 7 | 1 | 5 | 100 | 20 |...|
3 | 5 | 100 | 20 | *entry 8 | 1 | 4 | 110 | 10 |...|
-------------------------------------------------------
Figure 6:
FR-specific and ATM-specific VC MIB modules using
protocol-specific table indexing. Also shown are
the upward references within the Service Management
Architecture.
MIB modules, physical channel type MIB modules, or link
management protocol MIB modules into the Service Management
Architecture view---just have the appropriate OID value
point to the the appropriate entry in the new MIB module.
Rodemann Expires Dec 19, 1993 [Page 15]
Draft Service Management Architecture June 1993
5.3 Customer End-to-end View
The customer end-to-end view provides the correlating
information to view end-to-end virtual connections that span
through multiple service providers' networks. This
end-to-end view represents a multi-segment virtual
connection as a concatenation of individual service-provider
segments. The section of the Service Management
Architecture is very sketchy. An adequate definition of
this view requires much more discussion and experience.
Here is a sketchy initial stab at the information needed for
this end-to-end view. This is not in MIB format, i.e.,
having a table within a table, but this shows the type of
required information for this view. An entry in the
end-to-end MIB module may include:
+ end-to-end VC id
+ end-to-end VC status info
+ ordered list of VC Segments:
- VC Segment number
- VC Segment Provider info
- VC Segment status info
- point A port id
- point A VC id
- point B port id
- point B VC id
Note the use of generic terms "point A" and "point B". The
intent is to refrain from using terms like
Originating/Terminating and Source/Destination that suggest
a master-slave type of relationship. The only relationship
to be inferred from the terms point A and point B is the
polarization or orientation of individual VC segments, i.e.,
point B of the i'th segment is attached to point A of the
i+1'st segment.
Rodemann Expires Dec 19, 1993 [Page 16]
Draft Service Management Architecture June 1993
6. Summary
This document presents the Service Management Architecture
for defining Service MIB modules. The work is motivated by
the fundamental differences in management views and
functionality between a service provider and a service
customer. Differences between service provider and service
customer include whole-network vs. network-portion view,
direct vs. indirect management, and physical vs. logical
view. These fundamental differences suggest a difference in
philosophy between Service Management and Device Management.
The Service Architecture models a customer's view of a
shared network service as a logical configuration of ports,
access channels, and virtual connections. A service
customer indirectly manages the components within its
logical view, not the internals of the shared network.
Virtual connections that span across multiple service
providers' networks are viewed as concatenations of
individual service-provider segments.
Modeled upon the Service architecture, the Service
Management Architecture presents two views of virtual
connections: service-provider views and customer end-to-end
views. Service-provider views consist of single-segment
virtual connections established through a single service
provider's network, while customer end-to-end views consist
of multi-segment end-to-end virtual connections that span
across multiple service providers' networks.
This document discusses more of the service-provider view
than it does the customer end-to-end view. The
service-provider view consists of protocol-generic MIB
modules for defining configuration, with references to
protocol-specific MIB modules. This structure, along with
the use of protocol-generic port and virtual connection
identifiers, provides a clean Service Management
Architecture that promotes consistent views across various
underlying implementations and interworking of services.
Rodemann Expires Dec 19, 1993 [Page 17]
Draft Service Management Architecture June 1993
7. Security Considerations
Security issues are not discussed in this memo.
8. Author's Address
Kenneth R. Rodemann
AT&T Bell Laboratories
Room 1F-435A
101 Crawfords Corner Road
PO Box 3030
Holmdel, NJ 07733-3030
908-949-6229
krr@qsun.att.com
Rodemann Expires Dec 19, 1993 [Page 18]
Table of Contents
1. Status of this Memo................................. 1
2. Abstract............................................ 2
3. Introduction........................................ 3
4. Service Architecture................................ 5
5. Service Management Architecture..................... 7
5.1 Service-Provider View.......................... 7
5.2 Protocol-Generic/Protocol-Specific
Relationship................................... 10
5.3 Customer End-to-end View....................... 16
6. Summary............................................. 17
7. Security Considerations............................. 18
8. Author's Address.................................... 18
Rodemann Expires Dec 19, 1993 [Page 19]
